Entities often generate and use data that is important in some way to their operations. This data can include, for example, business data, financial data, and personnel data. If this data were lost or compromised, the entity may realize significant adverse financial and other consequences. Accordingly, many entities have chosen to back up some or all of their data so that in the event of a natural disaster, unauthorized access, or other events, the entity can recover any data that was compromised or lost, and then restore that data to one or more locations, machines, and/or environments.
While data backup is a valuable and important function, the ever increasing volume of data that is generated presents significant problems. In particular, many companies today find their backup and recovery processes strained as data growth in enterprise IT environment continues to accelerate at exponential rates, while data-protection solutions have struggled to keep pace.
At least some of the problems encountered in backup and restore systems, processes and environments concern the use of namespaces and associated memory. For example, a customer may create and use multiple namespaces in a single restore environment, domain or system, and non-volatile random-access memory (NVRAM) may be allocated to each of the namespaces. The NVRAM may be allocated for various reasons. By way of illustration, allocation of NVRAM to namespaces can improve performance in some instances, since the NVRAM may enable acceleration of namespace operations by allowing the filesystem to write the data into NVRAM and return, rather than writing to disk, then return. At a later time, the data written into NVRAM will be flushed onto disk for permanent storage purpose. The use of NVRAM in this way may also provide a measure of data protection in certain scenarios. For example, data written in NVRAM is relatively safe and can survive system crashes or power outage. In cases of a system crash, the NVRAM is used as a journaling device to recover the logged operations during system restart.
While the use of NVRAM can be advantageous in certain circumstances, it also introduces some problems. For example, because NVRAM is significantly more expensive than disk storage, the NVRAM resource in various environments is limited and each namespace can only be allocated a relatively small, fixed sized NVRAM. Thus, when the NVRAM is filled up, the logged data have to be flushed down to disk so that the NVRAM can be reused. Therefore, it is important to utilize the limited NVRAM space efficiently so as not to compromise system operations.
At least one approach to the utilization of NVRAM involves using pure physical NVRAM logging (PL) in namespace, that is, where the NVRAM will record the physical data of each transaction that is being updated, namely, the (key, value) pairs. One problem with this approach however is that it does not use the NVRAM space efficiently. For example, in some transactions, the same (key, value) pairs could be updated multiple times and, as a result, the PL design may record some redundant logs in the NVRAM. However, only the latest version needs to be logged because the previous versions will be overwritten by the most recent one.
Another approach to the utilization of NVRAM involves the use of a logical logging mechanism (LL). However, one significant disadvantage of LL is the extra burden it imposes to interpret/understand the operations (logical data) during recovery. As well, LL cannot always be directly applied into a file system because some types of transactions may involve the update of as few as a single pair of (key, data) values. In such circumstances, LL does not provide any improvement of logging efficiency. In fact, in these circumstances, the NVRAM footprint of LL can be even larger than that of a comparable PL approach.
In light of problems and shortcomings such as those noted above, it would be useful to be able to provide more efficient use of limited NVRAM resources in a computing environment. As well, it would be useful to have the flexibility to employ multiple different logging mechanisms in connection with the NVRAM resources. Correspondingly, it would be useful to be able to employ a hybrid logging approach that makes effective use of the advantageous aspects of various different logging processes for NVRAM resources, while avoiding or at least attenuating the impact of less advantageous aspects of those logging processes.